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1 Overview 

Zot is an agile and easily extendible bounded model checker, which can be 
downloaded at http://home.dei.polimi.it/pradella/. 

The tool supports different logic languages through a multi-layered ap- 
proach: its core uses PLTL, and on top of it a decidable predicative fragment 
of TRIO [8] is defined. An interesting feature of Zot is its ability to support 
different encodings of temporal logic as SAT problems by means of plug- 
ins. This approach encourages experimentation, as plug-ins are expected to 
be quite simple, compact (usually around 500 lines of code), easily modifi- 
able, and extendible. At the moment, a variant of the eventuality encoding 
presented in [2] is supported, (approximated) dense-time MTL [5], and a 
bi-infinite encoding [12], [13]. 

Zot offers three basic usage modalities: 

1. Bounded satisfiability checking (BSC): given as input a specification 
formula, the tool returns a (possibly empty) history (i.e., an execution 
trace of the specified system) which satisfies the specification. An 
empty history means that it is impossible to satisfy the specification. 

2. Bounded model checking (BMC): given as input an operational model 
of the system, the tool returns a (possibly empty) history (i.e., an 
execution trace of the specified system) which satisfies it. 

3. History checking and completion (HCC): The input file can also con- 
tain a partial (or complete) history H. In this case, if H complies with 
the specification, then a completed version of H is returned as output, 
otherwise the output is empty. 

The provided output histories have temporal length < k, the bound 
given by the user, but may represent infinite behaviors thanks to the loop 
selector variables, marking the start of the periodic sections of the history. 
The BSC/BMC modalities can be used to check if a property prop of the 
given specification spec holds over every periodic behavior with period < k. 
In this case, the input file contains spec A -iprop, and, if prop indeed holds, 
then the output history is empty. If this is not the case, the output history 
is a counterexample, explaining why prop does not hold. 
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2 Installation 



Zot's core is written in Common Lisp (with ASDF packaging http:/ /www. cliki.net/asdf) 
It can be used under Linux, Windows, or MacOS X, but has been tested 
only under Linux and Windows XP, using the following Common 



SBCL ( |http:// www.sbcl.org), 



CLISP (http://clisp.cons.org), 



CMUCL (http://www.cons.org/cmucl/), 



ABCL ([http://common-lisp.net/project/armedbear/ ), 



Clozure CL (http://www.clozure.com/clozurecl.html), 



This approach makes Zot an open system, as it uses Common Lisp also as 
internal scripting language of the tool, both to define complex verification 
activities, and to add new constructs and languages on top of the existing 
ones. 

Typically, to install Zot in a Debian system (or Ubuntu), the user must 
install a Common Lisp (e.g. one of the packages clisp, sbcl, cmucl, 
. . . ), and the common-lisp-controller package. To perform a system- 
wide install of the Zot packages, just put symbolic links to its .ads files in 
the /usr /share/common-lisp/systems/ directory. Note that it is possible to 
avoid a system- wide installation, but in this case the user has to work inside 
the main Zot directory. 

Zot works with external SAT-solvers. The supported SAT-solvers are 
MiniSat (default) [3], MiraXT [9], PicoSAT P, and zChaff 10J. Zot as- 
sumes that executable files called minisat, MiraXTSimp (optional), picosat 
(optional), zchaff (optional), are system-wide installed. 

A pre-packaged all-inclusive version for Windows ( WinZot, based on 
Cygwin-compiled binaries and SBCL) is available from the author. 

All Zot's components are available as open source software (GPL v2). 



1 SBCL and CMUCL are usually the fastest implementations, for running Zot. 
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3 Languages 

Being an open system, Zot supports different languages. At present, the 
main native language is PLTL (linear temporal logic with future and past 
operators). The other main layer based on PLTL is the metric temporal 
logic TRIO. 

Zot scripts are written in Common Lisp, so a basic knowledge of the 
language is required. It is very easy to find online a lot of tutorials and 
short presentations^. 

3.1 PLTL 

Propositional operators are written as: && (and), I I (or), ! ! (not). 

Predicates and propositional letters e.g., proposition Q is written (-P- 
Q); predicate Pred(l,2) is written as (-P- Pred 1 2). 

Quantifications 3t E {One, Two} : Formula(t) is written 

(-E- t ' (One Two) Formula(t) ) . -A- is the universal quantifier. 

Term comparisons and conditions are available through Common Lisp 
(e.g. eql, equal, <, <=, and, or, not, . . . ) 

Temporal operators The following temporal operators are supported: 
until, since, release, trigger, next, yesterday, zeta. The last one 
is the dual of yesterday, and is used only in the mono-infinite semantics. 

For the semantics of these operators, see e.g. [2] (which describes the 
implementation of the mono-infinite encoding in details). 

3.2 TRIO 

Zot was originally born as a satisfiability checker for the TRIO metric tem- 
poral logic [8]. 

The list of supported operators (and their correct "Zot spelling" ) is the 
following: 

dist 
futr 
past 

lasts lasts_ee lasts_ie lasts_ei lasts_ii 

lasted lasted_ee lasted_ie lasted_ei lasted_ii 

withinf withinf_ee withinf_ie withinf_ei withinf_ii 

withinp withinp_ee withinp_ie withinp_ei withinp_ii 

lasttime lasttime_ee lasttime_ie lasttime_ei lasttime_ii 

2 e.g. http://gigamonkey s.com/book/l is a good and freely available text. 
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nexttime 


nexttime. 


.ee nexttime. 


.ie nexttime. 


.ei nexttime 


somf 


somf _e 


somf _i 


som 




somp 


somp_e 


somp_i 






alwf 


alwf _e 


alwf _i 


alw 




alwp 


alwp_e 


alwp_i 






until 


until_ie 


until_ee 


until_ii 


until_ei 


since 


since_ie 


since_ee 


since_ii 


since_ei 



Bounded version of since and until are written as: 
(until_ie_<=_<= tl t2 A B) 

B will be true at t instants in the future with tl<=t<=t2 
(until_ie_>= tl A B) 

B will be true at t instants in the future with t>=tl 

since_ie_<=_<= 

since_ie_>= 

Caveat emptor! The default until is PLTL's (which is usually called 
until_ie in TRIO). For example, the following model satisfies (until A B) 
at 0: 

B 

AAAAAAAAAAAAAAAAAAAAA 

B may appear at 0. 
For MTL users: 

1. =t A (or D =t A)) is written (futr (-P- A) t); 

2. D< t A is written (lasts (-P- A) t); 

3. Q< t A is written (withinf (-P- A) t); 

4. + =t A (or M =t A)) is written (past (-P- A) t); 

5. M< t A is written (lasted (-P- A) t); 

6. +<tA is written (withinp (-P- A) t); 
with t > 0. 

3.3 Operational constructs 

Zot offers some simple facilities to describe operational systems, 
(define-item <varname> <domain>) 
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is used to define variables a la Von Neumann over finite domains (e.g. coun- 
ters). 

(def ine-array <varname> <index-domain> <domain>) 

is used to define mono-dimensional arrays. 

Example usage: 

(define-item cont (loop for i from to 9 collect i)) 
(def ine-array arr (loop for i from to 9 collect i) 

'(on off unknown)) 

In the spec, the user can e.g. write (cont= 6); (arr= 6 'off). 

Caveat: both define-item and define-array have side effects. It is there- 
fore wrong to "define-items" after a zot main procedure call, since successive 
calls may work with spurious constraints. It is therefore recommended to 
perform (clean-up) before defining items or arrays. 

Typically, to define an operational model means to constraint operational 
variables and arrays. This can be done either by using simple next-time 
formulae, i.e. containing only the next temporal operator, or by using the 
two dual constructs and-case and or-case [14J. 

To give the reader an idea of their semantics, here is an automatic trans- 
lation made by Zot on two simple examples. 

(and-case (x '(1 2) y '(3 4)) 

((-P- P x) (-P- Q x)) 
((-P- R y) (-P- Rl y)) 
(else (-P- R2 x) ) ) 

expands to 

(-A- X '(12) 

(-A- Y '(3 4) 

(&& (-> (-P- R Y) (-P- Rl Y)) (-> (-P- P X) (-P- Q X)) 
(-> (&& (! ! (-P- R Y)) (! ! (-P- P X))) (-P- R2 X))))) 

and 

(or-case (x ' (1 2) y ' (3 4)) 

((-P- P x) (-P- Q x)) 
((-P- R y) (-P- Rl y)) 
(else (-P- R2 x) ) ) 

expands to 

(-E- X '(12) 

(-E- Y '(3 4) 

(II (&& (-P- R Y) (-P- Rl Y)) (&& (-P- P X) (-P- Q X)) 
(&& (!! (-P- R Y)) (!! (-P- P X)) (-P- R2 X))))) 



3 LANGUAGES 



6 



3.4 MTL 

There is an experimental plug-in (called ap-zot for using a variant of dense- 
time MTL through approximation (see [5], and [3]). 
Here is a list of the time operator defined in ap-zot. 

until-b until-b-v until-b-~ 

since-b since-b-v since-b-~ 

release-b release-b-" release-b-v 

trigger-b trigger-b- ~ trigger-b-v 



until-b-inf 
since-b-inf 
release-b-inf 
trigger-b-inf 



until-b-v-inf 
since-b-v-inf 
release-b- ~-inf 
trigger-b- ~-inf 



until-b-~-inf 
since-b-~-inf 
release-b-v-inf 
trigger-b-v-inf 



diamond diamond-inf 
diamond-p diamond-inf -p 
box box-inf 
box-p box-inf-p 

The plug-in offers the following operations 

normalize 
basicize 

compute-gr anul ar i t y 
over-approximation 
under-approximation 
nth-divisor 

To compute over- and under-approximations, an axiom must be prepared 
through the two functions basicize and normalize 
(e.g. with (setf axl (normalize (basicize axl)))). 

The two functions over- approximation and under-approximation are used 
to compute the approximated formulae, while compute- granularity is used 
to set the p parameter (see [5] for details). 

The interested reader may find a complete example in coffee. lisp. 



3.5 Timed Automata 

Timed Automata (TA) are supported through a very experimental plug-in 
called ta-zot (see [6], [7]), which is based on the approximations offered by 
ap-zot. 

First, here is a list of the added operators, and approximations proce- 
dures: 



3 LANGUAGES 



7 



white-tri 
white-tri/3 
black-tri 
black-tri/3 

timed-automaton-under-f ormula 
timed-automat on-over-formula 

t imed-aut omat a-under-f ormul a 
timed-automata-over-formula 

Here is the main data structure used to represent TA's, together with 
its interface: 

(defstruct timed-automaton 
alphabet 
states 

initial-states 
clocks) 

(def generic add-trans (autom from to lamb constr)) 
(def generic add-label (autom state list-of -symbols) ) 
(def generic alpha (autom state)) 

(def generic get-trans-f rom-states (autom from to)) 
(def generic all-connected-pairs (autom)) 
(def generic all-unconnected-pairs (autom)) 
(def generic get-all-trans (autom)) 

(def generic get-trans-f rom-clock-reset (autom clock)) 

The interested reader may find a complete example in 
trans_prot . lisp . 
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4 Usage 

4.1 SAT-solvers 

The supported SAT-solvers are MiniSat [3] (which is used by default), Mi- 
raXT [9J, and zChaff [JO]. 

To use the zChaff SAT-solver, the user has to set the *zot-solver* pa- 
rameter. For example: 

(setq sat-interf ace : *zot-solver* :zchaff) 

MiraXT is a multi-threaded solver, so to use it we also have to choose 
the maximum number of threads that it will use: 

(setf sat-interf ace : *zot-solver* :miraxt) 
(setf sat-interf ace : *n-threads* 3) 

4.2 Model Checking 

To perform Bounded Model Checking, the user must provide the model 
through as argument transitions. Important: every variable used must be 
declared implicitly by e.g. an initialization formula as the second argument 
of Zot. 

Here is a simple example: mutex3 (a simple mutual exclusion protocol 
with three processes). 

The first part is used to load the mono-infinite plug-in, and defines the 
used variables. The first line loads the mono-infinite plug-in, called eezot. 
(bezot is the bi- infinite one.) 

(asdf : operate ' asdf : load-op 'eezot) 
(use-package :trio-utils) 

(defvar state-d ' (N T C)) 
(defvar turn-d '(1 2 3)) 

(def ine-array state turn-d state-d) 
(define-item turn turn-d) 

(def constant decl ; optional declarations, just for checking usage 
(append 

(loop for x in state-d append 

(loop for y in turn-d collect (state= y x))) 
(loop for x in turn-d collect (turn= x)))) 

Then, we define the system initialization and transitions: 
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(defvar init ; system initialization (at 0) 
(&& (-A- x turn-d (state= x 'N) ) 
(turn= 1))) 

(defvar trans ; list of model constraints 
(list 
(-A- p turn-d 

(or-case (x state-d) 

((state= p 'N) 
(next (state= p 'T))) 

((&& (state= p 'T) 

(II (-A- pi turn-d (-> (not (equal p pi)) 

(state= pi >N))) 

(turn= p))) 
(next (state= p 'C))) 

((state= p 'C) 
(next (state= p 'N) ) ) 

(else 
(&& (state= p x) 

(next (state= p x)))))) 

(or-case (x turn-d) ; — schedule — 

((&& (state= 1 'N) (state= 2 'T) (state= 3 'N) ) 

(next (turn= 2))) 
((&& (state= 1 'T) (state= 1 'N) (state= 3 'N) ) 

(next (turn= 1))) 
((&& (state= 1 'N) (state= 1 'N) (state= 3 'T)) 

(next (turn= 3))) 



; random choice policy 

((&& (state= 1 'T)(state= 2 'T)) 

(next (|| (turn= 1) (turn= 2)))) 
((&& (state= 1 'T)(state= 3 'T)) 

(next (|| (turn= 1) (turn= 3)))) 
((&& (state= 2 'T)(state= 3 'T)) 

(next (|| (turn= 2) (turn= 3)))) 

(else 

(&& (turn= x) (next (turn= x))))))) 
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As the reader may see, the transitions are defined as a list of constraints, 
which must hold on every instant of the time domain. 

We then write a simple property we wish to check on the system: 

(defvar spec 
(alw 
(&& 

(-> (turn= 1) (somf ( | | 
(-> (turn= 2) (somf ( | | 
(-> (turn= 3) (somf ( | | 



(turn= 2)(turn= 3)))) 
(turn= l)(turn= 3)))) 
(turn= l)(turn= 2))))))) 



The main procedure is called zot, and has two arguments: the time 
bound and the formula to be satisfied (plus some optional switches, e.g. 
transitions, declarations, :loop-free). 

To check if spec-0 holds for a time bound of 30, we perform: 



(eezot:zot 30 

(&& (yesterday init) 

(! ! spec)) 
: transitions trans 
: declarations decl 
) 



; time bound 

initialization (init must hold at 0) 
(negated) property 
list of model constraints 
(optional) declarations 



UNSAT means that the desired property holds. If the output is SAT, then 
spec does not hold and Zot returns a counter-example. 

4.3 Completeness 

A switch of the zot procedure (:loop-free, nil by default) is used to check 
completeness. In the previous example, we can check completeness by per- 
forming: 



(eezot:zot 30 

(yesterday init) 
transitions trans 
declarations decl 
: loop-free t 
) 



; time bound 

initialization (init must hold at 0) 
list of model constraints 
(optional) declarations 
check completeness 



UNSAT means that the completeness bound is reached. 



The zot procedure returns t if the spec is satisfiable, nil otherwise. So, 
it is possible to write a loop to actually find the completeness bound, e.g.: 
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(format t "Found: ~s~%" 

(loop for bound from 2 unless 
(eezot:zot bound 

(yesterday init) 
: transitions trans 
: declarations decl 
: loop-free t 
) 

return bound) ) 
4.4 Satisfiability Checking 

Let us now consider a simple example to show how satisfiability checking 
can be performed with Zot. 

The first line loads the bi-inifinite plug-in. 

(asdf : operate ' asdf : load-op 'bezot) 
(use-package :trio-utils) 

We then define the timed lamp spec: 

(defconstant delta 5) 

; Alphabet 

; on: the "on" button is pressed 

; off: the "off" button is pressed 

; L: the light is on 

(defconstant init 

(&&(!! (|| (-P- on)(-P- off)(-P- L))))) 

(defconstant the-lamp 
(alw (&& 

«-> 
(-P- L) 

(II (yesterday (-P- on)) 

(-E- x (loop for i from 2 to delta collect i) 
(&& (past (-P- on) x) 

(!! (withinP_ee (-P- off) x) ) ) ) ) ) 
(! ! (&& (-P- on) (-P- off)))))) 

To obtain a history compatible with the spec, we perform: 

(bezot: zot 10 

(&& init the-lamp)) 
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This is an example history generated by Zot, where **LOOP**, and 
**POOL** are the loop selector variables (**POOL** towards the past, 
**LOOP** towards the future): 

time 

time 1 

**L00P** 
ON 

time 2 

ON 
L 

time 3 

ON 
L 

time 4 

OFF 
L 

time 5 

OFF 

time 6 

OFF 

time 7 

OFF 

time 8 

OFF 

time 9 

**P00L** 
OFF 

time 10 



end 
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4.5 Temporary data 

Zot uses four files to save temporary data during the verification activity: 

1) output.cnf.txt 

2) output.sat.txt 

3) output.hist.txt 

(1) contains the resulting boolean formula of the system (in the stan- 
dard DIMACS CNF format); (2) is the output of the SAT-solver; (3) is the 
resulting trace of the system (e.g. a TRIO history). 
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5 Architecture 

Zot's architecture is based on a PLTL-to-SAT core, which interacts with 
the "outside world" through a TRIO-based interface and different plug-ins. 
The core itself is structured as a plug-in, so that different encodings can be 
defined and used. 

More recently (May 2009), we added two plugins to Zot, natively sup- 
porting metric operators (like lasts, withinf). These native metric plugins 
are called meezot (mono-infinite), and mbezot. Their usage is exactly the 
same as eezot and bezot [H] . 

5.1 PLTL-to-SAT encodings 

As said before, Zot's core is based on encoding PLTL into SAT. At present 
two main encodings are available in the standard distribution: eezot, which 
is a standard eventuality-based encoding on a mono-infinite time domain 
(N, see e.g. [2]), and the bi-infinite one, bezot [12] on Z. 

The two encodings are packaged (as asdf systems) in the following files: 

eezot. lisp eezot. asd 
bezot. lisp bezot. asd 

The file kripke . lisp contains the basic data structure and the definition 
of the genericso 

(defclass kripke () 

(; time bound i.e. [0..k] 
(the-k : accessor kripke-k) 

; number of used prop, variables 
(numvar : accessor kripke -numvar) 

; formula -> integer data structure (hash-table) 
(the-list : accessor kripke-list) 

; integer -> formula data structure (hash-table) 
(the-back : accessor kripke-back) 

; list of propositional letters 
(sf-prop : accessor kripke-prop) 

; list of used boolean subformulae 
(sf-bool : accessor kripke-bool) 

3 kripke does not actually contain a Kripke structure - names of data structures and 
generics come from previous, forsaken incarnations of the tool-set. 
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; list of used future-tense subf . 
(sf-futr : accessor kripke-futr) 

; list of used past-tense subf. 
(sf-past : accessor kripke-past) 

; n. of props used in the encoding 
(max-prop : accessor kripke-maximum) 

; resulting SAT formula 

(the-f ormula : accessor kripke-f ormula) ) ) 

There is also an old variant of eezot, called ezot, which supports virtual 
unrollings (as presented in [2J, usually called 5), so its data structure is 
extended through inheritance. The user may change the default behavior 
(i.e. 5 = 0), by setting ezot:*FIXED-DELTA* to nil, which tells eezot to 
actually compute 5, or (s)he may change to set it to a fixed meaningful 
value. 

The call generic translates a formula/proposition and a time instant into 
an integer (the SAT-solver proposition); se//must be an instance of kripke 
(or of a subclass). 

(def generic call (self obj the-time &rest other-stuff)) 

The back-call generic is used to translate an integer in [0..k] into the cor- 
responding subformula; self must be an instance of kripke (or of a subclass). 

(def generic back-call (self x)) 
(def generic back-call-time (self x)) 

5.2 Main Interface 

There are two interfaces: 

sat-interf ace . lisp 

the first one is with the SAT-solver, and it is used to send the output of the 
PLTL encoding to it; then, to parse its output and get a counter-example, 
if any. 

The other one, 

trio-utils . lisp 

is the basic interface with the user, and is based on TRIO (see Section [3.2h 
augmented with the operational constructs covered in Section [3.31 



5 ARCHITECTURE 



16 



5.3 Other modules and plug-ins 

At present just ap-zot and ta-zot are available. Please refer to Sections 13.41 
13.51 an d the related papers. 

The two plug-ins are implemented and packaged (as asdf systems) in 

ap-zot. lisp ap-zot. asd 
ta-zot. lisp ta-zot. asd 

ta-zot is based on ap-zot, which uses TRIO as underlying language (through 
the trio-utils interface). 
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